1. Field of the Invention
The invention relates to debug support in microprocessors, and more particularly to providing debug ports to support debug operations.
2. Description of the Related Art
The growth in software complexity, coupled with increasing processor clock speeds, has placed an increasing burden on application software developers. The cost of developing and debugging new software products is now a significant factor in processor selection. A processor's failure to adequately facilitate software debug results in longer customer development times and reduces the processor's attractiveness for use within industry. The need to provide software debug support is particularly acute within the embedded products industry, where specialized on-chip circuitry is often combined with a processor core.
In addition to the software engineer, other parties are also affected by debug tool configuration. These parties include: the "trace" algorithm developer who must search through captured software trace data that reflects instruction execution flow in a processor; the in-circuit emulator developer who deals with problems of signal synchronization, clock frequency and trace bandwidth; and the processor manufacturer who does not want a solution that results in increased processor cost or design and development complexity.
With desktop systems, complex multitasking operating systems are currently available to support debugging. However, the initial task of getting these operating systems running reliably often requires special development equipment. While not the standard in the desktop environment, the use of such equipment is often the approach taken within the embedded industry. Logic analyzers, read-only memory (ROM) emulators and in-circuit emulators (ICE) are frequently employed. In-circuit emulators do provide certain advantages over other debug environments, offering complete control and visibility over memory and register contents, as well as overlay and trace memory in case system memory is insufficient. Use of traditional in-circuit emulators, which involves interfacing a custom emulator back-end with a processor socket to allow communication between emulation equipment and the target system, is becoming increasingly difficult and expensive in today's age of exotic packages and shrinking product life cycles.
Assuming full-function in-circuit emulation is required, there are a few known processor manufacturing techniques able to offer the required support for emulation equipment. Most processors intended for personal computer (PC) systems utilize a multiplexed approach in which existing pins are multiplexed for use in software debug. This approach is not particularly desirable in the embedded industry, where it is more difficult to overload pin functionality.
Other more advanced processors multiplex debug pins in time. In such processors, the address bus is used to report software trace information during a BTA--(Branch Target Address) cycle. The BTA-cycle, however, must be stolen from the regular bus operation. In debug environments where branch activity is high and cache hit rates are low, it becomes impossible to hide the BTA-cycles. The resulting conflict over access to the address bus necessitates processor "throttle back" to prevent loss of instruction trace information. In the communications industry, for example, software typically makes extensive use of branching and suffers poor cache utilization, often resulting in 20% throttle back or more. This amount of throttling is unacceptable amount for embedded products which must accommodate real-time constraints.
In another approach, a second "trace" or "slave" processor is combined with the main processor, with the two processors operating in-step. Only the main processor is required to fetch instructions. The second, slave processor is used to monitor the fetched instructions on the data bus and keeps its internal state in synchronization with the main processor. The address bus of the slave processor functions to provide trace information. After power-up, via a JTAG (Joint Test Action Group) input, the second processor is switched into a slave mode of operation. Free from the need to fetch instructions, its address bus and other pins provide the necessary trace information.
Another existing approach involves building debug support into every processor, but only bonding-out the necessary signal pins in a limited number of packages. These specially packaged versions of the processor are used during debug and replaced with the smaller package for final production. This bond-out approach suffers from the need to support additional bond pad sites in all fabricated devices. This can be a burden in small packages and pad limited designs, particularly if a substantial number of extra pins are required by the debug support variant. Additionally, the debug capability of the specially packaged processors is unavailable in typical processor-based production systems.
In yet another approach (the "Background Debug Mode" by Motorola, Inc.) limited on-chip debug circuitry is provided for basic run control. Through a dedicated serial link requiring additional pins, this approach allows a debugger to start and stop the target system and apply basic code breakpoints by inserting special instructions in system memory. Once halted, special commands are used to inspect memory variables and register contents. This serial link, however, does not provide trace support--additional dedicated pins and expensive external trace capture hardware are required to provide instruction trace data.
As mentioned, an additional tool available to the embedded project is the ROM emulator. The ROM emulator replaces system ROM or RAM with a dual ported memory which can be accessed by both the target and host processors. The use of a ROM emulator does provide for fast data and program transfer, which is the primary reason for its selection.
The traditional full-function ICE solution is the most expensive in terms of hardware support. That solution can cost $12K to $15K. The availability of full-function ICE to debuggers is therefore limited because of its high cost. A lower cost approach such as provided by the Motorola BDM approach is strongly preferred by the majority of software engineers because of its relative simplicity from a software engineer's perspective and low cost. A low cost solution can range from a H/W cost of only $100 to several thousand dollars.
Typically, a project can have one or two hardware engineers and six to eight software engineers. Such a project may be able to afford one full function ICE for the project. Thus, most of the software engineers need to be supported by a low-cost option. However, the low cost option may provide for relatively slow data and program transfer.
Thus, the current solutions for software debugging suffer from a variety of limitations, including: increased packaging and development costs, circuit complexity, processor throttling, and bandwidth matching difficulties. Further, there is currently no adequate low-cost procedure for providing trace information. The limitations of the existing solutions are likely to be exacerbated in the future as internal processor clock frequencies continue to increase. It would be desirable to provide support for both the high end user requiring ICE equipment and the low end user satisfied with available serial debug interfaces. Further, it would be desirable to attract both users wanting full function debug capability including high speed access as well as the lower end slower speed access.